Add new dotnet tool packages Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm #121282

Copilot · 2025-11-03T00:42:16Z

Status: Implementation Complete ✅

Successfully implemented RID-specific tool packages for Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm as new separate packages, following the design at https://github.com/dotnet/designs/blob/main/accepted/2025/rid-specific-tool-packages.md.

Important: The existing Microsoft.NETCore.ILAsm and Microsoft.NETCore.ILDAsm packages remain unchanged as content packages to avoid breaking downstream consumers.

Implementation

New Dotnet Tool Packages (Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm)

Configured as DotnetTool package type
RID-specific packages include native binaries in tools/net10.0/<rid>/
Primary packages dynamically generate tool manifest with $(PackageVersion) substitution
Hardcoded RID list to support distributed builds across multiple machines
TargetRid entry with Exclude pattern for automatic community platform support
Separate from existing packages - no breaking changes to Microsoft.NETCore.ILAsm and Microsoft.NETCore.ILDAsm

Existing Packages Preserved (Microsoft.NETCore.ILAsm and Microsoft.NETCore.ILDAsm)

Remain as content packages in their original format
No breaking changes for existing consumers
Continue to work as before for projects using Microsoft.NET.Sdk.IL and other SDK consumers

Tool Manifests

DotnetToolSettings.xml - RID-specific package manifest with executable runner type
Primary manifest generated dynamically during build to use current $(PackageVersion)
Includes all supported RIDs including community platforms (FreeBSD)
Automatically includes $(TargetRid) using Exclude="@(_OfficialRID)" pattern

Package Names and Commands

Package: Microsoft.dotnet-ilasm → Command: dotnet-ilasm
Package: Microsoft.dotnet-ildasm → Command: dotnet-ildasm

Supported RIDs

Windows: win-x64, win-x86, win-arm64
Linux: linux-x64, linux-arm, linux-arm64, linux-musl-x64, linux-musl-arm64
macOS: osx-x64, osx-arm64
Community platforms: freebsd-x64, freebsd-arm64
Plus any $(TargetRid) not in the official list (automatically excluded if duplicate)

Package Structure

Primary Packages (Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm):

tools/net10.0/any/DotnetToolSettings.xml (generated with RID list and current version)

RID-Specific Packages (e.g., runtime.linux-x64.Microsoft.dotnet-ilasm):

tools/net10.0/linux-x64/DotnetToolSettings.xml
tools/net10.0/linux-x64/ilasm

RID-Specific Packages (e.g., runtime.linux-x64.Microsoft.dotnet-ildasm):

tools/net10.0/linux-x64/DotnetToolSettings.xml
tools/net10.0/linux-x64/ildasm

Benefits

✅ Smaller downloads (only RID-specific package for current platform is downloaded)
✅ No managed wrapper overhead - native binaries run directly
✅ Native performance with executable runner type
✅ Consistent with .NET tool packaging design
✅ No hardcoded versions - automatically uses build system version
✅ Works in distributed build environments (different RIDs on different machines)
✅ Includes community platform support (FreeBSD)
✅ Automatically supports new community RIDs via $(TargetRid) with simple Exclude pattern
✅ Clear usage documentation in package descriptions
✅ Simple, maintainable implementation following ILCompiler pattern
✅ Both ILAsm and ILDAsm now available as dotnet tools
✅ Existing packages unchanged - no breaking changes for downstream consumers

Verification

New dotnet-ilasm package:

Package ID: Microsoft.dotnet-ilasm
Command: dotnet-ilasm
Supports RID-specific tool package pattern
No conflicts with existing Microsoft.NETCore.ILAsm package

New dotnet-ildasm package:

Package ID: Microsoft.dotnet-ildasm
Command: dotnet-ildasm
Supports RID-specific tool package pattern
No conflicts with existing Microsoft.NETCore.ILDAsm package

Existing packages preserved:

Microsoft.NETCore.ILAsm - unchanged content package format
Microsoft.NETCore.ILDAsm - unchanged content package format

Usage

dotnet-ilasm

# Install the tool (uses new package name)
dotnet tool install -g Microsoft.dotnet-ilasm

# Invoke the tool (uses new command name)
dotnet-ilasm mycode.il -dll -output:myassembly.dll

# Get help
dotnet-ilasm -?

dotnet-ildasm

# Install the tool (uses new package name)
dotnet tool install -g Microsoft.dotnet-ildasm

# Invoke the tool (uses new command name)
dotnet-ildasm myassembly.dll

# Get help
dotnet-ildasm -?

Building Locally

# Build CoreCLR runtime and packages
./build.sh -subset clr.runtime+clr.packages -c Release

# Or build just the packages if runtime is already built
./build.sh -subset clr.packages -c Release

Packages will be in: artifacts/packages/Release/Shipping/

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Co-authored-by: jcouv <[email protected]>

src/coreclr/tools/dotnet-ilasm/Program.cs

jkotas · 2025-11-03T06:03:34Z

src/coreclr/tools/dotnet-ilasm/Program.cs

@@ -0,0 +1,167 @@
+// Licensed to the .NET Foundation under one or more agreements.


This wrapper should not be needed.

Instead, we should create RID specific tool packages - https://github.com/dotnet/designs/blob/main/accepted/2025/rid-specific-tool-packages.md .

You're right - I'll update the implementation to use RID-specific tool packages instead of a managed wrapper. This will eliminate the wrapper and directly use the native ilasm binary as the entry point with the executable runner type as described in the design document.

jcouv · 2025-11-04T05:26:18Z

@copilot src/coreclr/tools/dotnet-ilasm/dotnet-ilasm.csproj:6

Could we instead use .NET 6.0 as TargetFramework and the RollForward attribute, as explained in https://andrewlock.net/using-and-authoring-dotnet-tools/#ensuring-compatibility-by-multi-targeting ? #Closed

Copilot · 2025-11-04T05:46:44Z

@copilot src/coreclr/tools/dotnet-ilasm/dotnet-ilasm.csproj:6

Could we instead use .NET 6.0 as TargetFramework and the RollForward attribute, as explained in https://andrewlock.net/using-and-authori...

Since we're switching to RID-specific tool packages based on @jkotas's feedback, there won't be a managed wrapper anymore - the native ilasm binary will be the entry point directly. The target framework concern will no longer apply. #Closed

…kages Co-authored-by: jcouv <[email protected]>

jcouv · 2025-11-04T08:14:13Z

@copilot Please proceed with the next steps you listed

Co-authored-by: jcouv <[email protected]>

Copilot · 2025-11-04T08:40:57Z

@copilot Please proceed with the next steps you listed

Implemented RID-specific tool packages in commit 5b66f25. The solution:

Creates RID-specific packages (e.g., runtime.linux-x64.Microsoft.NETCore.ILAsm) with native ilasm binary as direct entry point
Primary package (Microsoft.NETCore.ILAsm) includes tool manifest referencing all RID-specific packages
Uses executable runner type - no managed wrapper needed
Verified working: tool installs and executes ilasm successfully

The packages can now be installed with dotnet tool install -g Microsoft.NETCore.ILAsm and the native ilasm binary runs directly without any wrapper overhead.

am11 · 2025-11-04T09:53:44Z

Should ildasm be also packed as tool?

ps - it's sad that single package doesn't support multiple commands dotnet/sdk#16708, otherwise we could have Microsoft.NETCore.ILTools with both ilasm and ildasm packed together.

src/coreclr/.nuget/Microsoft.NETCore.ILAsm/DotnetToolSettings.primary.xml

Copilot · 2025-11-06T20:03:38Z

@copilot Expand this PR to do the same for ILDasm

Added ILDAsm tool package support in 24646d1. The implementation follows the same pattern as ILAsm:

Created DotnetToolSettings.xml with executable runner
Updated Microsoft.NETCore.ILDAsm.pkgproj with tool manifest generation
Added RID-specific package support with all official and community RIDs
Enhanced package description with usage examples

Both tools can now be installed as:

dotnet tool install -g Microsoft.NETCore.ILAsm (command: ilasm)
dotnet tool install -g Microsoft.NETCore.ILDAsm (command: ildasm)

jcouv · 2025-11-06T20:19:45Z

It is probably a good idea anyway to make sure that this change does not break the VMR builds.

Copied the modified files over to dotnet/dotnet in PR dotnet/dotnet#3262

src/coreclr/.nuget/Microsoft.NETCore.ILDAsm/Microsoft.NETCore.ILDAsm.pkgproj

Co-authored-by: Adeel Mujahid <[email protected]>

jcouv · 2025-11-07T04:28:36Z

The VMR build failed:

azure-pipelines
/ dotnet-unified-build (VMR Vertical Build Windows_x64)
src\winforms\src\Accessibility\src\Accessibility.ilproj#L0

src\winforms\src\Accessibility\src\Accessibility.ilproj(0,0): error NU1212: (NETCORE_ENGINEERING_TELEMETRY=Restore) Invalid project-package combination for runtime.win-x64.Microsoft.NETCore.ILAsm 10.0.0-ci. DotnetToolReference project style can only contain references of the DotnetTool type

There was a similar problem with some other consumers (copied below).

Did some digging to understand how these project reference ILAsm packages:

the Accessibility projects use "Microsoft.NET.Sdk.IL" SDK (from Microsoft.NET.Sdk.IL.targets.template at /workspaces/dotnet/src/runtime/src/coreclr/.nuget/Microsoft.NET.Sdk.IL/Microsoft.NET.Sdk.IL.targets.template)
the projects under source-build-reference-packages pull in /workspaces/dotnet/src/source-build-reference-packages/src/targetPacks/Directory.Build.props which has <RestoreIlTooling>true</RestoreIlTooling>

##[error]src/source-build-reference-packages/src/targetPacks/ILsrc/microsoft.aspnetcore.app.ref/6.0.2/Microsoft.AspNetCore.App.Ref.6.0.2.csproj(0,0): error NU1212: (NETCORE_ENGINEERING_TELEMETRY=Restore) Invalid project-package combination for runtime.centos.10-x64.Microsoft.NETCore.ILAsm 10.0.0-ci. DotnetToolReference project style can only contain references of the DotnetTool type 
  /__w/1/s/src/source-build-reference-packages/src/targetPacks/ILsrc/microsoft.aspnetcore.app.ref/6.0.2/Microsoft.AspNetCore.App.Ref.6.0.2.csproj : error NU1212: Invalid project-package combination for runtime.centos.10-x64.Microsoft.NETCore.ILAsm 10.0.0-ci. DotnetToolReference project style can only contain references of the DotnetTool type  [/__w/1/s/.dotnet/sdk/10.0.100-ci/NuGet.targets]
##[error]src/source-build-reference-packages/src/targetPacks/ILsrc/microsoft.aspnetcore.app.ref/6.0.2/Microsoft.AspNetCore.App.Ref.6.0.2.csproj(0,0): error NU1212: (NETCORE_ENGINEERING_TELEMETRY=Restore) Invalid project-package combination for runtime.centos.10-x64.Microsoft.NETCore.ILDAsm 10.0.0-ci. DotnetToolReference project style can only contain references of the DotnetTool type 
  /__w/1/s/src/source-build-reference-packages/src/targetPacks/ILsrc/microsoft.aspnetcore.app.ref/6.0.2/Microsoft.AspNetCore.App.Ref.6.0.2.csproj : error NU1212: Invalid project-package combination for runtime.centos.10-x64.Microsoft.NETCore.ILDAsm 10.0.0-ci. DotnetToolReference project style can only contain references of the DotnetTool type  [/__w/1/s/.dotnet/sdk/10.0.100-ci/NuGet.targets]

jcouv · 2025-11-11T05:02:32Z

@copilot Change of plans... The conversion from a content package to a dotnet-tool package breaks downstream consumers.
Let's put the existing packages back the way they were and introduce separate packages for dotnet-tools.
The packageIDs should be Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm.
The command names/shims should be "dotnet-ilasm" and "dotnet-ildasm"

…mers Co-authored-by: jcouv <[email protected]>

Copilot · 2025-11-11T05:29:06Z

@copilot Change of plans... The conversion from a content package to a dotnet-tool package breaks downstream consumers.
Let's put the existing packages back the way they were and introduce separate p...

Implemented in 5de2013. Created new separate packages:

New Packages:

Microsoft.dotnet-ilasm (command: dotnet-ilasm)
Microsoft.dotnet-ildasm (command: dotnet-ildasm)

Existing Packages:

Microsoft.NETCore.ILAsm - reverted to original content package format
Microsoft.NETCore.ILDAsm - reverted to original content package format

This approach avoids breaking existing consumers that use the packages as content packages while providing new dotnet tool packages with the requested naming.

jcouv · 2025-11-11T06:28:39Z

@copilot Can we use PackAsTool functionality and avoid manual package creation (why we have to create your own dotnet tool settings.xml files?)

Copilot · 2025-11-11T06:49:23Z

@copilot Can we use PackAsTool functionality and avoid manual package creation (why we have to create your own dotnet tool settings.xml files?)

The manual DotnetToolSettings.xml files are necessary because ilasm and ildasm are native binaries, not managed .NET assemblies. PackAsTool only works for managed executables (C# projects).

For native binaries, we need to:

Use runner="executable" in the manifest (instead of the default dotnet runner for managed tools)
Manually create RID-specific packages with the native binaries
Follow the RID-specific tool packages design (https://github.com/dotnet/designs/blob/main/accepted/2025/rid-specific-tool-packages.md)

This is the same approach used by other native tools in the .NET ecosystem that need to be packaged as dotnet tools.

jkotas · 2025-11-11T07:19:01Z

src/coreclr/.nuget/Microsoft.dotnet-ilasm/Microsoft.dotnet-ilasm.pkgproj

+    <_OfficialRID Include="linux-musl-arm64" />
+    <_OfficialRID Include="osx-x64" />
+    <_OfficialRID Include="osx-arm64" />
+    <_OfficialRID Include="freebsd-x64" />


freebsd RID is not necessary here per earlier discussion #Resolved

jkotas · 2025-11-11T07:20:50Z

src/coreclr/.nuget/Microsoft.dotnet-ilasm/Microsoft.dotnet-ilasm.proj

@@ -0,0 +1,11 @@
+<Project Sdk="Microsoft.Build.Traversal">
+  <PropertyGroup>
+    <IsILToolPackage>true</IsILToolPackage>


What is the IsILToolPackage property for? Delete it? (It can be deleted from the existing project files as well.) #Resolved

If I remove it, things build fine locally in a local build.

Apparently, the property only matters in specific cross-compilation scenarios when BuildHostILTools=true, which is used during certain infrastructure builds where you need the tool for a different architecture than the target.
Since the existing project files have it, I think it's safer to keep.

Copilot AI self-assigned this Nov 3, 2025

Initial plan

e95560e

Copilot AI assigned jcouv Nov 3, 2025

Copilot started work on behalf of jcouv November 3, 2025 00:42 View session

jkotas added the area-ILTools-coreclr label Nov 3, 2025

Copilot AI and others added 3 commits November 3, 2025 01:18

Add dotnet-ilasm tool wrapper for native ilasm binary

0c9236f

Co-authored-by: jcouv <[email protected]>

Update Microsoft.NETCore.ILAsm package to publish as dotnet tool

80c73b2

Co-authored-by: jcouv <[email protected]>

Add musl detection for Linux RID resolution

860365e

Co-authored-by: jcouv <[email protected]>

Copilot AI changed the title ~~[WIP] Update the ilasm package to publish ilasm a dotnet tool~~ Add dotnet tool support to Microsoft.NETCore.ILAsm package Nov 3, 2025

Copilot AI requested a review from jcouv November 3, 2025 01:33

Copilot finished work on behalf of jcouv November 3, 2025 01:33

teo-tsirpanis reviewed Nov 3, 2025

View reviewed changes

src/coreclr/tools/dotnet-ilasm/Program.cs Outdated Show resolved Hide resolved

This was referenced Nov 3, 2025

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

Failed to install runtime_python_requirements #114924

Open

jkotas reviewed Nov 3, 2025

View reviewed changes

Copilot started work on behalf of jcouv November 4, 2025 05:26 View session

Remove managed wrapper based on feedback to use RID-specific tool pac…

a970702

…kages Co-authored-by: jcouv <[email protected]>

Copilot AI changed the title ~~Add dotnet tool support to Microsoft.NETCore.ILAsm package~~ [WIP] Investigate RID-specific tool packages for Microsoft.NETCore.ILAsm Nov 4, 2025

Copilot finished work on behalf of jcouv November 4, 2025 05:50

Copilot started work on behalf of jcouv November 4, 2025 08:14 View session

Implement RID-specific tool packages for Microsoft.NETCore.ILAsm

5b66f25

Co-authored-by: jcouv <[email protected]>

Copilot AI changed the title ~~[WIP] Investigate RID-specific tool packages for Microsoft.NETCore.ILAsm~~ Implement RID-specific tool packages for Microsoft.NETCore.ILAsm Nov 4, 2025

Copilot finished work on behalf of jcouv November 4, 2025 08:41

jcouv reviewed Nov 4, 2025

View reviewed changes

src/coreclr/.nuget/Microsoft.NETCore.ILAsm/DotnetToolSettings.primary.xml Outdated Show resolved Hide resolved

Copilot started work on behalf of jcouv November 4, 2025 10:34 View session

This was referenced Nov 6, 2025

[android-arm64] The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#6408

Open

Certificate issues when Sending To Helix from Apple platforms dotnet/dnceng#6410

Open

Copilot AI changed the title ~~Implement RID-specific tool packages for Microsoft.NETCore.ILAsm~~ Implement RID-specific tool packages for Microsoft.NETCore.ILAsm and ILDAsm Nov 6, 2025

Copilot finished work on behalf of jcouv November 6, 2025 20:05

Copilot started work on behalf of jcouv November 6, 2025 20:06 View session

jcouv added a commit to jcouv/dotnet that referenced this pull request Nov 6, 2025

Port dotnet/runtime/pull/121282 for validation (don't merge)

bb793d1

Copilot finished work on behalf of jcouv November 6, 2025 20:34

jcouv reviewed Nov 6, 2025

View reviewed changes

src/coreclr/.nuget/Microsoft.NETCore.ILDAsm/Microsoft.NETCore.ILDAsm.pkgproj Outdated Show resolved Hide resolved

Apply suggestions from code review

ac2b506

Co-authored-by: Adeel Mujahid <[email protected]>

build-analysis bot mentioned this pull request Nov 7, 2025

Known Test Repository Issue Sometimes Misses Test Failures dotnet/dnceng#6411

Open

3 tasks

Copilot started work on behalf of jcouv November 11, 2025 05:03 View session

Create separate dotnet tool packages to avoid breaking existing consu…

5de2013

…mers Co-authored-by: jcouv <[email protected]>

Copilot AI changed the title ~~Implement RID-specific tool packages for Microsoft.NETCore.ILAsm and ILDAsm~~ Add new dotnet tool packages Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm Nov 11, 2025

Copilot AI requested a review from jcouv November 11, 2025 05:31

Copilot finished work on behalf of jcouv November 11, 2025 05:31

Copilot started work on behalf of jcouv November 11, 2025 06:29 View session

Copilot finished work on behalf of jcouv November 11, 2025 06:51

jkotas reviewed Nov 11, 2025

View reviewed changes

Julien Couvreur and others added 2 commits November 11, 2025 00:08

Copy previous approach

15653eb

Various fixes

572f34b

This was referenced Nov 11, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

System.Security.Cryptography.X509Certificates.Tests fails on Linux #120527

Open

		@@ -0,0 +1,167 @@
		// Licensed to the .NET Foundation under one or more agreements.

Add new dotnet tool packages Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm #121282

Are you sure you want to change the base?

Add new dotnet tool packages Microsoft.dotnet-ilasm and Microsoft.dotnet-ildasm #121282

Conversation

Copilot AI commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Status: Implementation Complete ✅

Implementation

Benefits

Verification

Usage

dotnet-ilasm

dotnet-ildasm

Building Locally

Uh oh!

Uh oh!

jkotas Nov 3, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 4, 2025

Choose a reason for hiding this comment

Uh oh!

jcouv commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI commented Nov 4, 2025 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcouv commented Nov 4, 2025

Uh oh!

Copilot AI commented Nov 4, 2025

Uh oh!

am11 commented Nov 4, 2025

Uh oh!

Uh oh!

Copilot AI commented Nov 6, 2025

Uh oh!

jcouv commented Nov 6, 2025

Uh oh!

Uh oh!

jcouv commented Nov 7, 2025

Uh oh!

jcouv commented Nov 11, 2025

Uh oh!

Copilot AI commented Nov 11, 2025

Uh oh!

jcouv commented Nov 11, 2025

Uh oh!

Copilot AI commented Nov 11, 2025

Uh oh!

jkotas Nov 11, 2025 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Nov 11, 2025 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jcouv Nov 11, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Copilot AI commented Nov 3, 2025 •

edited

Loading

jcouv commented Nov 4, 2025 •

edited

Loading

Copilot AI commented Nov 4, 2025 •

edited by jcouv

Loading

jkotas Nov 11, 2025 •

edited by jcouv

Loading

jkotas Nov 11, 2025 •

edited by jcouv

Loading